Availability Considerations in Network Design

One of the performance factors considered during network design is availability. There are many ways of defining network availability. In this paper, we explain why a new measure could be useful, establish requirements that a new availability measure should satisfy, propose a new measure satisfying these requirements and give examples of its application to a 3tier architecture. We show how to calculate the measure in polynomial time and give numerical examples. 1. Goals and Motivation During network design, three performance factors must typically be taken into account: delay, throughput and dependability. In particular, dependability may be defined in several ways, the two most common being reliability and availability. System reliability is defined as the probability that the system will be operational up to a certain point of time. This measure of dependability is especially important for critical networks that must stay up; this would be the case, for example, in a hospital network where patients' lives could depend on certain systems being functional. Availability, on the other hand, is more suitable as a measure of dependability for networks that must be operational, on average, rather than continuously. This is what is desired for most networks. An organization that does business through a network needs that network to be operational most of the time to minimize lost business. Availability is measured as a percentage. This paper deals with network availability from a network designer's point of view. The designer's perspective is different from an operational perspective since the designer must deal with availability a priori, that is, before the network is built and operational. One problem when dealing with network availability is that a network is made up of many components and has many users. What does it mean to say that the network is available 99.97% of the time? Many definitions of availability have been proposed in the literature. We outline the main ones below: 1. The probability of the network being connected. A network is connected when all device pairs can communicate [1][4][3][5][10][13][14][15]; 2. The probability of all paths between two specific devices being operational [3][4][7]; 3. The probability that all operational devices can communicate with a specific device [4][9]; 4. The probability that a specific number of devices can communicate with one another [8]; 5. The number of device pairs that can communicate [4][8][10][14]; 6. The number of devices that can communicate with a specific device [4][9]; 7. The fraction of devices that can communicate with one another [10]. In this paper, we propose the use of a new availability measure based on networks services. The reason we chose not to use other measures defined in the literature is that we have found that none of these measures can be communicated to organizations' top management in a visceral way. Simply put, managers do not relate any of these measures to the business, since the measures are not couched in their language. As a result, it becomes innocuous to use these measures while designing a network. A solution to the problem would have to create a new availability measure, suitable for communication with an organization's top management and would provide tools for network design based on the new measure. This paper tackles the first problem: that of defining a new, more appropriate network availability measure and showing that it may be calculated efficiently. 2. Definition of a New Availability Measure 2.1 Requirements for the new measure In our view, an ideal network availability measure should satisfy the following 4 requirements: 1. The measure must make business sense. In other words, it is fundamental that the measure be related to business objectives in a way that allows a nontechnical manager to understand the availability measure and relate it to his or her perception of what the network does for the business. In short, people must understand it easily. Failing to do this means that the designer will not be able to communicate effectively with the organization's management about network requirements and design alternatives. 2. The measure must be technically sound. This means that the measure must be adequately formalized, and must capture availability correctly, in the sense that a higher value for the measure must mean that the network is somehow "better" or more available. Failure to do this will jeopardize the ability to include the measure in a formal design methodology. 3. The measure must be relatively easy to define. In other words, assuming that the measure will depend on several network parameters, these parameters must ideally be few and their value easy to estimate. Possible parameters are network topology, device failure rates or MTBF, etc. Failure to satisfy this requirement means that the measure will be so difficult to capture that network designers will not think it worth the effort to use it in their design methodology, even when aided with good design tools. 4. The measure must be efficient to calculate, even if only heuristically. Failure to satisfy this requirement will obviously preclude the use of the measure for large networks. We consider any polynomial-time algorithm to be efficient, as opposed to algorithms with exponential-time complexity. 2.2 A measure that make business sense Let us tackle the first requirement. What makes business sense when speaking of availability? Remembering that the network is a means to an end, we must focus on the end. The importance of networks to users is the effect they have. As far as network users are concerned, it is not important that a particular router be up; in the users' view, network services must be operational. Since a network offers many services to many different users, lets us first look at availability from a single user's perspective: to a user, the network is operational as long as he or she obtains full services from it. In order to factor in the whole user population, we suggest that network availability be measured as the fraction of users receiving full services. A service could, for example, be file server access, an e-mail service, access to a corporate database, or workgroup software, etc. A service is considered to be operational from a particular user's point of view when all resources required to provide the service to this user are operational. Assuming that the user accesses the services through a desktop client host, these resources could include client hardware, client software, communication links and interconnection equipment forming a path from the client to all required servers, server hardware, server software, and so on. Observe that, while the above definition treats all services as equal and all users as equal, it gives more weight to more important resources. If a main Domain Name System (DNS) server goes down and name resolution can no longer be done, all clients may suffer and network availability will be zero (no clients will be receiving full services). On the other hand, a problematic access-level switch may affect a few tens of users while a client host going down would affect a single user. We believe that this definition captures business requirements appropriately and that it can be transmitted and understood intuitively by non-technical managers. 2.3 The new availability measure: model and definition Moving on to the second requirement − technical soundness − we must now formalize the above ideas. A network consists of hosts, interconnection equipment and communication links. Basic assumptions are that any of these components can assume two states: operational or failed and that all failures are independent. There are nt total components. Component i has availability pi (0 ≤ pi < 1). We also let qi = 1− pi. We now consider the possible network failure states. In a network with nt components susceptible to failure, there are 2 nt possible failure states. Failure states are denoted by Sk, where 1 ≤ k ≤ 2 t. We have S1 = φ (no component has failed), S2 = {1} (component number 1 has failed), S3 = {2} and so on up to state S 2 nt where all network components have failed. We associate a probability P(Sk) to state Sk of the network being in that state: